
# ods 接入数据，保持数据原样，进行压缩，分区
# dwd 数据清洗，脱敏，列式存储，构建明细宽表
# dws 数据服务层；整合某个领域数据服务层，基于上层应用和产品指标要求，构建公共粒度的汇总指标表，构建命名规范，口径一致的统计指标
# ads MySQL redis， es分析某一主题域的服务数据，面相应用逻辑加工


# yarn ： 7180
# spark history ： 8088
# hdfs ： 9870
# hue ： 8888
# hive ： 10002



# ---------------------------------- hive ---------------------------------------
# hadoop 之上套壳 hive sql 翻译成 mapreduce 提交给 yarn计算
# 解释器-编译器-优化器-执行器 最终编程 mapreduce 程序

# 解释器：sql转化为抽象语法树
# 编译器：将它编译成执行计划

# 优化器
# 谓词下推 ： 过滤条件下推到数据源， 读取数据的时候过滤， 减少数据传输量
# 列裁剪：分区裁剪
# 使用索引

# 执行器：将逻辑执行计划转为物理执行计划

# 文件格式： 
# textfile：无压缩，编码，原来多大，到hdfs多大， hive不进行数据切分，不能并行操作，查询效率低，适合小数据
# sequencefile：二进制kv存储，底层交互友好，性能更快，可压缩，分割，优化磁盘利用率，可并行操作，查询效率高，
#         按记录压缩（值压缩，也就是value），块压缩（多个值形成一个块，进一步压缩）
#         stored as sequencefile
#         只能 insert into xxx select * from xxx;

# textfile、sequencefile ： 行存储， 按行查询性能好，案列存储性能不高，插入数据比较容易

# RCFile、ORC、Parquet： 列存储，插入数据比较麻烦
# partuent: 案列压缩，压缩比例更大，不支持 update，inser，delete， --- spark支持更好
# ORC ： 压缩比 parquent 压缩 比例更大，支持索引和矢量化查询，加载时性能消耗大，需要通过 text文件转化生成，读取全量数据性能查，使用hive中大型存储查询
#     orc 有行有列， 先按行分割表（250M）， 再每组内进行按列存储


# 跟数据库对比：不建议修改；大规模数据量计算优势；延迟相对较高
# 内部表：删除时元数据和原始数据都会删除，用于自己测试
# 外部表：删除时 只会删除 元数据，用于生产

# 常用函数：date_add，date_sub，collect_set，data_format，NVL，
# order by：全局排序，不用
# sort by：分区排序

# union 合并，去重， 效率比较 union all差一点，因为union all 不去重
# 底层 NULL 是以 \N 存储的
# sqoop 避免  hive 和 mysql 空值不一致（NULL）
# 导出数据时采用–input-null-string和–input-null-non-string两个参数。导入数据时采用–nullstring和–null-non-string。


# 将数据量较小相对分散的表放左边，使用map join 让小标先进入内存，hive3以后 不需要自己区分小表和大表，
# 通过 set hive.mapjoin.smalltable.filesize = xxx; 设置小表

# 合并小文件： set hive.input.format = org.apache.hadoop.hive.ql.io.combinehiveInputFormat;

# 合理设置reduce个数，有多少个reduce就有多少个文件















# ---------------------------------- hdfs ---------------------------------------
# 1个文件块，占用namenode 150字节内存
# 128G能存储多少文件块？ 128 * 102410241024byte/150字节 = 9亿文件块
# 解决小文件问题： 归档 har 将多个小文件成一个大文件； 从用 jvm 计算




# datanode --3s--> 发送心跳包 给 namenode
# namenode --10次没收到（30秒）---> 主动给datanode发消息(每5分钟一次) ---- 两次没收到表示datanode宕机了
# datanode 宕机了，namenode 会将它上面的数据主动备份一份到其他机器上













# ---------------------------------- yarn ---------------------------------------
# resource manager ： 负责资源的分配于调度，接收客户端请求、监控nodemanager以及appmaster
# nodemanager： 管理本机资源， 处理resourcemanager 于 app manager相关命令
# application master ： 运行再nodemanager 节点中， 负责想 resourcemanager申请资源分配给内部任务
                # 负责任务的监控，容错以及销毁（每个job任务都有一个对应的appmaster)






# ResourceManager 包括 ApplicationManager + Resource Scheduler

# client --MR任务-->  application manager 找一个空闲的 NodeManager
# ------> nodemanager 创建一个appmaster ----->  appmaster 告知 resourcemanager 自己的状态，保持心跳
# ------->  appmaster 向resourcemanager 申请任务所需资源（container）  -------- resourcemanager 返回哪个nodemanager有资源可用
# ------ appmaster 通知 响应的 nodemanger 给对应的 mr 计算任务分配 container 并保持心跳
# -----执行任务的nodemanager 不断的上报任务的执行进度，最终返回结束










# ---------------------------------- 建模 ---------------------------------------

# 主题域： 市场主体；市场媒介；市场事件；其他
# 主题： 媒介：基金信托券商
#         事件：资讯，经营，诉讼，投融资
#         主体：企业，政府机构，保险，银行，个人，社会组织，等等

# 主体围绕媒介和事件

# 1. 选择业务过程：选择业务方感兴趣的业务线，如支付、下单、物流等，一条线对应一张事实表  ---- 确认主体
# 2. 声明粒度：数仓中数据保存细化程度或综合程度级别    ----  每个事实表要描述什么东西，表怎么建有哪些字段
#         订单事实表中：一行数据表示订单中的一个商品项
#         支付事实表：一行表示一个支付记录
# 3. 确定维度：（分析问题角度）维度描述业务的事实情况；主要表示：谁 ，何处，何时，等信息；  ---  哪些是要分析的角度
#         确定维度的原则：后续需求中是否需要分析相关维度指标，如：需要统计什么时间下的订单多，哪个地区下的订单多等；
#                         需要确定维度：时间维度，地区维度，等

# 4. 确定事实： 就是确定的指标，具体分析哪些指标，如订单金额，下单次数，  ---  确认分析的指标
#         dwd层以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的事实表，可以适当宽表化处理